파이프 (유닉스)

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 역사
3. 구현
4. 셸에서의 사용
5. 프로그래밍 방식의 파이프 생성
6. UNIX 계열 이외 OS의 유사 기능
- 6.1. MS-DOS
- 6.2. Windows의 명명된 파이프
참조

1. 개요

파이프는 유닉스 셸에서 한 프로그램의 출력을 다른 프로그램의 입력으로 연결하는 데 사용되는 프로세스 간 통신(IPC) 메커니즘이다. 더글러스 매클로이가 유닉스 개발 중 파이프라인 개념을 고안했으며, 켄 톰슨이 `pipe()` 시스템 호출과 함께 파이프라인을 구현했다. 파이프는 `|` 문자를 사용하여 셸에서 명령을 연결하며, 각 프로세스는 표준 스트림을 통해 데이터를 주고받는다. 파이프는 익명 파이프와 명명된 파이프로 나뉘며, 다른 운영 체제에서도 유사한 기능이 구현되었다.

더 읽어볼만한 페이지

운영체제 기술 - 프로세스
프로세스는 컴퓨터에서 실행되는 프로그램의 인스턴스로, 운영 체제가 시스템 자원을 효율적으로 관리하며 멀티태스킹 환경에서 독립적인 실행 흐름을 유지한다.
운영체제 기술 - 커널 (컴퓨팅)
커널은 운영 체제의 핵심으로, 하드웨어와 소프트웨어 간 상호 작용을 관리하며 시스템 보안, 자원 관리, 하드웨어 추상화, 프로세스 스케줄링, 프로세스 간 통신, 다중 작업 환경 지원 등의 기능을 제공하고, 모놀리식, 마이크로, 혼합형 커널 등으로 구현되며 가상화 및 클라우드 컴퓨팅 환경에서 중요성이 커지고 있다.

파이프 (유닉스)
파이프 (컴퓨터 과학)
종류	프로세스 간 통신
데이터 흐름 방향	단방향
구현	FIFO 버퍼를 통해 구현
사용 분야	유닉스 셸 소프트웨어 파이프라인
유닉스 파이프
정의	유닉스 및 유닉스 계열 운영 체제에서 사용되는 프로세스 간 통신 (IPC)의 한 형태 한 프로그램의 출력을 다른 프로그램의 입력으로 연결하는 메커니즘
기호	"\|" (파이프 문자)
작동 방식	한 프로세스의 표준 출력을 다른 프로세스의 표준 입력으로 리디렉션 데이터를 임시 버퍼에 저장하고, 다음 프로세스가 데이터를 읽도록 함
예시	ls -l \| grep ".txt"
설명	"ls -l" 명령어의 출력을 "grep ".txt"" 명령어의 입력으로 전달 현재 디렉토리에서 ".txt" 확장자를 가진 파일 목록을 표시
장점	간단하고 직관적인 인터페이스 프로그램 간의 결합도를 낮춤 복잡한 작업을 여러 개의 작은 프로그램으로 분할하여 처리 가능
단점	단방향 통신만 지원 데이터를 메모리 버퍼에 저장하므로, 대용량 데이터 처리 시 성능 저하 가능성 존재
역사	더글러스 매클로이가 켄 톰슨에게 제안하여 유닉스에 도입 멀틱스의 I/O 리디렉션에서 영감을 받음
유사 개념	명명된 파이프 (FIFO)
소프트웨어 파이프라인
정의	일련의 데이터 처리 요소들을 연결하여 데이터 흐름을 생성하는 구조 각 요소는 이전 요소의 출력을 입력으로 받아 처리하고, 결과를 다음 요소로 전달
구성 요소	단계 (Stages): 데이터를 처리하는 개별 요소 버퍼 (Buffers): 단계 간 데이터 전송을 위한 임시 저장 공간
특징	병렬 처리 가능 모듈화된 설계 유연성 및 확장성
예시	컴파일러: 소스 코드 -> 어셈블리 코드 -> 오브젝트 코드 -> 실행 파일 그래픽 파이프라인: 3D 모델 -> 렌더링 -> 디스플레이
장점	전체 시스템의 처리량 향상 유지보수 및 디버깅 용이 새로운 기능 추가 용이
단점	파이프라인 설계 복잡성 단계 간 데이터 전송 오버헤드 발생 가능성

2. 역사

파이프라인 개념은 더글러스 매클로이(Douglas McIlroy)가 유닉스 개발 초기 벨 연구소에서 제안했으며, 명령 셸에서 한 프로그램의 출력 파일을 다른 프로그램의 입력으로 전달하는 경우가 많다는 것을 발견했다.^[4]^[5] 이 개념은 1973년 켄 톰슨이 유닉스에 구현했다.^[17]

2. 1. 유닉스 탄생과 파이프라인

더글러스 매클로이는 벨 연구소에서 유닉스 개발에 참여하면서, 명령어 셸에서 한 프로그램의 출력을 다른 프로그램의 입력으로 전달하는 경우가 많다는 점에 착안하여 파이프라인 개념을 고안했다.^[1]^[4]^[5]^[17] 1973년 켄 톰슨은 `pipe()` 시스템 호출과 함께 파이프라인을 셸 및 버전 3 유닉스의 여러 유틸리티에 추가하여 이 아이디어를 구현했다.^[6]^[17] 켄 톰슨은 `|` 표기법을 제안했으며, 버전 4에서 파이프 구문의 설명을 크게 단순화했다.^[6]

켄 로크너가 1960년대 다트머스 시분할 시스템을 위해 개발한 '통신 파일'은 유닉스 파이프와 관련이 있으며, 이를 선행했지만,^[7]^[8]^[19]^[20] 유닉스 파이프는 이와는 독립적으로 개발되었다.

2. 2. 다른 운영 체제로의 확산

유닉스의 이 기능은 MS-DOS, VM/CMS, MVS의 CMS 파이프라인 패키지 등 다른 운영 체제에서 차용되었으며, 결국 소프트웨어 공학의 파이프 및 필터 설계 패턴으로 지정되었다. 이후 MS-DOS, OS/2, Microsoft Windows, BeOS 등 다른 운영 체제의 명령줄 셸에도 거의 동일한 표기법으로 파이프가 채택되었다.^[18]

애플(Apple Inc.)사의 macOS도 Mac OS X부터 유닉스 운영 체제가 되었으므로 파이프를 동일하게 사용할 수 있게 되었다. Automator의 아이콘도 파이프를 가진 로봇으로, 이것 역시 파이프라인의 개념을 응용한 소프트웨어이다.^[21]

2. 3. 초기 유사 기능과의 비교

유닉스 파이프는 1960년대 켄 로크너가 다트머스 시분할 시스템(DTSS)을 위해 개발한 '통신 파일'과 관련이 있지만, 독립적으로 개발되었다.^[7]^[8]^[20] 유닉스 파이프 이전에 비슷한 기구로는 1960년대 켄 로크너가 DTSS 상에서 구현한 'communication files'가 있었다.^[19]

3. 구현

파이프라인은 프로세스 간 통신(IPC) 메커니즘의 일종으로, 메시지 전달 방식을 사용한다. 파이프라인은 각 프로세스의 표준 출력이 다음 프로세스의 표준 입력으로 직접 전달되도록 프로세스 집합을 표준 스트림으로 연결한다. 두 번째 프로세스는 첫 번째 프로세스가 실행 중일 때 시작되며, 동시적으로 실행된다.^[10]

대부분의 유닉스 계열 시스템에서 파이프라인의 모든 프로세스는 동시에 시작되며, 스트림이 적절하게 연결되고, 스케줄러에 의해 다른 프로세스와 함께 관리된다.

파이프를 사용하면 여러 프로그램을 조합하여 다양하고 복잡한 데이터 처리를 효율적이고 유연하게 실행할 수 있다. 또한 현존하는 소프트웨어 자산의 재사용이 가능하므로 프로그램 생산성 측면에서도 이점이 있다.

데이터 처리 과정은 입력 데이터, 처리 프로그램, 출력 데이터의 3가지 요소로 구성된다. 복잡한 처리를 하나의 프로그램으로 만들면 버그나 보수성 악화를 유발할 수 있다. UNIX나 유닉스 계열 OS에서는 "하나의 일만 잘하는 도구"를 파이프라인으로 조합하는 방식을 사용한다. 즉, 복잡한 처리를 기능별로 작게 분할하고, 단순한 소프트웨어로 처리한 후, 그 출력(중간 결과)을 다음 소프트웨어의 입력으로 전달하는 방식(파이프로 연결)을 반복한다. 이러한 방식을 위해 설계된 프로그램을 필터라고 부른다.

파이프와 관련된 시그널로 `SIGPIPE`가 있다. 파이프의 읽기 측이 닫힌 후 쓰기가 수행되면, 쓰기를 시도했던 프로세스에 `SIGPIPE`가 전달된다. 기본적으로 `SIGPIPE`를 수신한 프로세스는 이상 종료한다. 이는 파이프에 쓰는 프로세스가 쓰기를 계속하면 버퍼가 고갈되어 블록되는 상황을 방지하기 위함이다.^[15]

3. 1. 익명 파이프와 명명된 파이프

프로세스 간 통신에 사용되는 파이프라인은 표준 스트림을 통해 프로세스들을 연결하며, 한 프로세스의 표준 출력이 다음 프로세스의 표준 입력으로 전달되도록 한다. 이러한 파이프에는 두 가지 주요 유형이 있다.

익명 파이프: 직접적인 부모 자식 관계에 있는 프로세스 간 통신을 위해 fork 전에 공유된다. 셸에서 세로 막대(`|`) 기호를 사용하여 쉽게 생성할 수 있으며, 한 프로세스의 표준 출력을 다른 프로세스의 표준 입력에 직접 연결한다.
이름있는 파이프: 부모 자식 관계가 아닌 프로세스 간 통신을 위해 사용되며, 파일 시스템에 이름 공간을 가진다. POSIX (UNIX)에서는 `mkfifo()` 또는 `mknod()`를 사용하여 생성할 수 있다.^[14] 이름있는 파이프는 마치 파일처럼 열 수 있으며, 파일 기술자는 파이프의 파일 기술자처럼 취급된다.

셸에서 익명 파이프는 `|` 기호를 통해 쉽게 사용할 수 있다. 프로세스 군의 표준 스트림을 연결하여 어떤 프로세스의 표준 출력을 다른 프로세스의 표준 입력으로 직접 연결한다.

이름있는 파이프는 셸 명령 조작에서도 유용하다. `mkfifo` 명령으로 이름있는 파이프를 만들 수 있다. 예를 들어, `cp -r` 명령으로 대규모 파일 트리를 복사하는 것이 실패할 수 있는 경우, `tar` 명령을 사용하여 이름있는 파이프를 출력 대상으로 지정할 수 있다. 이렇게 하면, 전개 대상으로 이동하거나 `ls` 명령으로 상황을 확인한 후, 이름있는 파이프를 입력으로 사용하여 `tar` 명령으로 안전하게 전개할 수 있다.

3. 2. 버퍼링

파이프라인은 프로세스 간 통신에 사용되며, 일반적으로 운영체제는 파이프의 버퍼링 기능을 제공한다.^[10] 예를 들어, 송신 프로그램이 초당 5000 바이트를 생성하고 수신 프로그램이 초당 100바이트만 수신할 수 있지만, 데이터는 손실되지 않는다.^[10] 대신 송신 프로그램의 출력은 큐에 보관된다.^[10] 수신 프로그램이 데이터를 읽을 준비가 되면 파이프라인의 다음 프로그램이 큐에서 읽는다. 큐가 가득 차면 수신자가 큐에서 적어도 일부 데이터를 제거할 때까지 송신 프로그램이 중지(블로킹)된다. 리눅스에서 버퍼의 크기는 65,536바이트(64KiB)이다.^[10]

3. 3. 네트워크 파이프

넷캣이나 소캣과 같은 도구를 사용하면 파이프를 TCP/IP 소켓에 연결할 수 있다.

4. 셸에서의 사용

대부분의 유닉스 셸은 파이프라인을 생성하기 위한 특수 구문 구조를 제공하며, `|` (파이프 문자)를 사용하여 명령을 연결한다.

표준 셸 구문에서, 여러 명령은 세로 막대(`|`)로 구분되어 나열된다. 셸은 이 명령들을 프로세스로 실행하고, 각 프로세스의 표준 스트림을 연결하여, 왼쪽 명령의 표준 출력이 오른쪽 명령의 표준 입력으로 전달되도록 한다. 이러한 연결은 운영 체제에 구현된 익명 파이프라는 프로세스 간 통신 메커니즘을 통해 이루어진다. 파이프는 단방향으로 작동하며, 데이터는 왼쪽에서 오른쪽으로 흐른다.

`grep 札幌市 Address.txt | a2ps | lpr`와 같은 파이프 사용 예시에서, `|`는 셸에게 파이프를 지시하는 기호이다. 이 명령어는 ''Address.txt'' 파일에서 "札幌市"가 포함된 행을 출력하고, ''a2ps'' 명령어로 서식을 지정한 후, ''lpr'' 명령어로 인쇄하는 세 단계를 순차적으로 처리한다.

파이프를 사용하면 중간 파일을 생성하는 방식에 비해 처리 속도가 빠르고, 메모리 사용량이 적으며, 여러 프로그램을 동시에 실행하여 효율성을 높일 수 있다. 이는 UNIX의 설계 철학인 툴킷 접근법과 분할 정복의 성공적인 사례로 평가받는다.

4. 1. 기본 사용법

널리 사용되는 모든 유닉스 셸은 파이프라인을 생성하기 위한 특수한 구문 구조를 가지고 있다. 명령어를 순서대로 작성하고, ASCII 세로 막대 문자 `|` (이 때문에 종종 "파이프 문자"라고 불림)로 구분한다. 셸은 프로세스를 시작하고 표준 스트림 간의 필요한 연결(일정량의 버퍼 저장 포함)을 설정한다.

파이프라인은 익명 파이프를 사용한다. 익명 파이프의 경우, 한 프로세스에서 기록된 데이터는 다음 프로세스에서 읽을 때까지 운영 체제에 의해 버퍼링되며, 이 단방향 채널은 프로세스가 완료되면 사라진다. 이는 메시지가 파일로 만들어 명명된 파이프에서 주고받으며 프로세스가 완료된 후에도 유지되는 명명된 파이프와 다르다. 익명 파이프에 대한 표준 셸 구문은 여러 명령을 세로 막대("파이프"는 일반적인 유닉스 용어)로 구분하여 나열하는 것이다.

```text

command1 | command2 | command3

```

예를 들어, 현재 디렉토리의 파일을 나열하고(`ls`), `"key"` 문자열을 포함하는 `ls` 출력 줄만 유지하고(`grep`), 스크롤링 페이지로 결과를 보려면(`less`), 사용자는 터미널의 명령줄에 다음을 입력한다.

```text

ls -l | grep key | less

```

`ls -l` 명령은 프로세스로 실행되며, 해당 출력(stdout)은 `grep key` 프로세스의 입력(stdin)으로 파이프된다. `less` 프로세스도 마찬가지다. 각 프로세스는 이전 프로세스에서 입력을 받아 ''표준 스트림''을 통해 다음 프로세스에 출력을 생성한다. 각 `|`는 셸에게 운영 체제에 구현된 (익명) 파이프라는 프로세스 간 통신 메커니즘을 통해 왼쪽 명령의 표준 출력을 오른쪽 명령의 표준 입력에 연결하도록 지시한다. 파이프는 단방향이며, 데이터는 파이프라인을 통해 왼쪽에서 오른쪽으로 흐른다.

다음은 전형적인 파이프 사용 예시이다. `|` (수직 막대)는 셸에 파이프를 지시하는 기호이다.

```text

grep 札幌市 Address.txt | a2ps | lpr

```

위 명령어는 다음 세 가지 처리를 지시한다.

1. 파일 ''Address.txt''에서 "札幌市"가 포함된 행을 출력한다.

2. 1의 출력을 입력으로 받아 ''a2ps'' 명령어를 사용하여 서식을 지정한다.

3. 2의 출력을 인쇄한다.

파이프를 사용하지 않고 중간 파일을 이용하는 방법도 있다.

```text

grep 札幌市 Address.txt > sapporo.txt

a2ps < sapporo.txt > print.ps

lpr < print.ps

```

이 방법도 있지만, 파이프를 이용하는 방법에 비해 기술이 불필요하게 길어질 뿐만 아니라, 일반적으로 처리 속도가 느려진다.

중간 파일을 만드는 경우 첫 번째 프로그램이 모든 데이터를 처리 완료할 때까지 기다린 후, 두 번째 프로그램이 실행되고, 또한 두 번째 프로그램이 종료된 후에야 세 번째 프로그램을 실행해야 하기 때문이다. 그러나 파이프를 사용하면, 세 개의 프로그램을 멀티태스킹으로 동시에 실행하고, I/O 등 시간이 걸리는 처리의 대기 시간을 효과적으로 사용할 수 있다.

게다가, 순차 처리를 하기 때문에, 데이터의 크기가 큰 경우에도 기억 영역을 소비하지 않는 이점도 있다. 또한, 데이터의 전달이 메모리 상에서 이루어지기 때문에, 그 점에서도 빠른 처리가 기대된다.

파이프나 중간 파일을 이용하는 방법 외에도, 프로그래밍 언어를 이용하여 전용 소프트웨어를 작성하여 처리하는 방법도 있다. 하지만, 파이프를 이용하면 기존의 UNIX 명령만으로 빠르게 실현하고 싶은 처리를 실현할 수 있다. 특히 한 번만 실행하는 처리에 대해 전용 소프트웨어를 작성하는 것은 과잉이며, 생산성의 측면에서도 파이프가 우수하다.

UNIX의 설계 사상인, 각각의 역할에 특화된 프로그램을 조합하여, 복잡한 기능을 실현하는 (툴킷 접근법, 분할 정복)으로서, 파이프는 그 성공 사례이며, UNIX를 이용하는 매력 중 하나이다.^[1]

4. 2. 예시

모든 유닉스 셸은 pipeline^영어을 생성하기 위한 특수한 구문 구조를 가지고 있다. 명령을 순서대로 작성하고, ASCII 세로 막대(`|`, "파이프 문자"라고도 불림)로 구분한다. 셸은 프로세스를 시작하고 표준 스트림 간의 필요한 연결 설정을 한다.

예를 들어, 현재 디렉토리의 파일을 나열하고(`ls`), "key" 문자열을 포함하는 `ls` 출력 줄만 유지하고(`grep`), 스크롤링 페이지로 결과를 보려면(`less`), 다음과 같이 입력한다.

```bash

ls -l | grep key | less

```

`ls -l` 명령은 프로세스로 실행되며, 해당 출력(stdout)은 `grep key` 프로세스의 입력(stdin)으로 파이프된다. `less` 프로세스도 마찬가지다. 각 프로세스는 이전 프로세스에서 입력을 받아 ''표준 스트림''을 통해 다음 프로세스에 출력을 생성한다. 각 `|`는 셸에게 운영 체제에 구현된 익명 파이프라는 프로세스 간 통신 메커니즘을 통해 왼쪽 명령의 표준 출력을 오른쪽 명령의 표준 입력에 연결하도록 지시한다. 파이프는 단방향이며, 데이터는 파이프라인을 통해 왼쪽에서 오른쪽으로 흐른다.

다음은 URL로 표시된 웹 리소스에 대한 맞춤법 검사기 구현 예시이다.

```bash

curl "https://ko.wikipedia.org/wiki/파이프_(유닉스)" |

sed 's/[^a-zA-Z ]/ /g' |

tr 'A-Z ' 'a-z\n' |

grep '[a-z]' |

sort -u |

comm -23 - <(sort /usr/share/dict/words) |

less

```

'''`curl`'''은 웹 페이지의 HTML 내용을 가져온다.
'''`sed`'''는 웹 페이지 콘텐츠에서 공백이나 문자가 아닌 모든 문자를 공백으로 바꾼다.
'''`tr`'''은 대문자를 소문자로 바꾸고 텍스트 줄의 공백을 줄 바꿈 문자로 변환한다.
'''`grep`'''은 소문자 알파벳 문자가 하나 이상 포함된 줄만 포함한다 (빈 줄을 제거).
'''`sort`'''는 '단어' 목록을 알파벳순으로 정렬하고 `-u` 스위치는 중복을 제거한다.
'''`comm`'''은 두 파일 간의 공통된 줄을 찾는다. `-23`은 두 번째 파일에만 있는 줄과 두 파일 모두에 공통된 줄을 억제하고 첫 번째 파일에서만 발견된 줄만 남긴다. 파일 이름 대신 `-`를 사용하면 `comm`이 표준 입력(파이프 라인)을 사용한다. `sort /usr/share/dict/words`는 `comm`이 예상하는 대로 `words` 파일의 내용을 알파벳순으로 정렬하고 `<( ... )`는 결과를 임시 파일로 출력하며(`프로세스 치환`을 통해) `comm`이 읽는다.
'''`less`'''를 사용하면 사용자가 결과를 페이지별로 볼 수 있다.

다음은 전형적인 파이프 사용 예시이다. `|` (수직 막대)는 셸에 파이프를 지시하는 기호이다.

```bash

grep 札幌市 Address.txt | a2ps | lpr

```

이는 파일 ''Address.txt''에서 "札幌市"가 포함된 행을 출력하고, 그 출력을 입력으로 받아 ''a2ps'' 명령어를 사용하여 서식을 지정하고, 그 출력을 인쇄하는 처리를 지시한다.

파이프를 사용하는 방법 외에 중간 파일을 이용하는 방법도 있지만, 파이프를 이용하는 방법에 비해 기술이 불필요하게 길어질 뿐만 아니라, 일반적으로 처리 속도가 느려진다. 중간 파일을 만드는 경우 첫 번째 프로그램이 모든 데이터를 처리 완료할 때까지 기다린 후, 두 번째 프로그램이 실행되고, 또한 두 번째 프로그램이 종료된 후에야 세 번째 프로그램을 실행해야 하기 때문이다. 그러나 파이프를 사용하면, 세 개의 프로그램을 멀티태스킹으로 동시에 실행하고, I/O 등 시간이 걸리는 처리의 대기 시간을 효과적으로 사용할 수 있다.

또한, 순차 처리를 하기 때문에, 데이터의 크기가 큰 경우에도 기억 영역을 소비하지 않는 이점이 있다. 데이터의 전달이 메모리 상에서 이루어지기 때문에 빠른 처리가 기대된다.

UNIX의 설계 사상인, 각각의 역할에 특화된 프로그램을 조합하여 복잡한 기능을 실현하는 (툴킷 접근법, 분할 정복)으로서, 파이프는 그 성공 사례이며, UNIX를 이용하는 매력 중 하나이다.

4. 3. 에러 스트림 처리

기본적으로, 파이프라인의 프로세스에서 생성된 표준 에러 스트림(stderr)은 파이프를 통해 전달되지 않고, 대신 콘솔로 전송된다. 그러나 많은 셸은 이러한 동작을 변경하기 위한 추가 구문을 가지고 있다. 예를 들어, csh 셸에서는 `|` 대신 `|&`를 사용하면 표준 에러 스트림도 표준 출력과 병합되어 다음 프로세스로 전달된다.^[11] Bash 셸은 버전 4.0부터^[11] `|&`를 사용하여 표준 에러를 병합하거나 `2>&1`을 사용하여 병합하고, 다른 파일로 리디렉션할 수도 있다.^[16]

4. 4. Pipemill

가장 일반적인 단순 파이프라인에서 셸은 파이프를 통해 일련의 하위 프로세스를 연결하고 각 하위 프로세스 내에서 외부 명령을 실행한다. 따라서 셸 자체는 파이프라인을 통해 흐르는 데이터를 직접 처리하지 않는다.

하지만 셸이 직접 처리를 수행하는 것도 가능한데, 이를 '''밀''' 또는 '''파이프밀'''(pipemill^영어)이라고 한다. 이는 while^bash 명령이 초기 명령의 결과를 "밀"하는 데 사용되기 때문이다. 이 구조는 일반적으로 다음과 같다.

```bash

command | while read -r var1 var2 ...; do

# 각 줄을 처리하고, var1, var2 등으로 구문 분석된 변수를 사용한다.

# (이것은 서브셸일 수 있습니다: while 루프가 종료된 후 var1, var2 등은 사용할 수 없습니다. zsh 및 최신 버전의 Korn 셸과 같은 일부 셸은 파이프 연산자의 왼쪽에 있는 명령을 서브셸에서 처리합니다.)

done

```

이러한 파이프밀은 루프 본문에 cat^영어 및 ssh^영어와 같이 stdin에서 읽는 명령이 포함된 경우 의도대로 수행되지 않을 수 있다.^[12] 루프의 첫 번째 반복에서 이러한 프로그램(이를 "drain"이라고 부른다)은 command^영어에서 남은 출력을 읽고, 루프는 종료된다(결과는 drain의 세부 사항에 따라 다름). 이러한 동작을 피할 수 있는 몇 가지 방법이 있다. 먼저, 일부 drains는 stdin^영어에서 읽기를 비활성화하는 옵션을 지원한다(예: ssh -n^영어). 또는 drain이 유용한 작업을 수행하기 위해 stdin^영어에서 입력을 읽을 ''필요''가 없는 경우, < /dev/null^영어을 입력으로 제공할 수 있다.

파이프의 모든 구성 요소는 병렬로 실행되므로, 셸은 일반적으로 하위 프로세스(서브셸)를 fork하여 해당 내용을 처리하므로 외부 셸 환경으로 변수 변경 사항을 전파하는 것이 불가능하다. 이 문제를 해결하기 위해, "파이프밀"은 대신 here document에서 공급될 수 있으며, here document에는 파이프라인이 실행을 완료할 때까지 기다린 후 내용을 밀링하는 command substitution이 포함되어 있다. 또는 named pipe 또는 process substitution을 사용하여 병렬 실행을 수행할 수 있다. GNU bash는 또한 마지막 파이프 구성 요소에 대한 포킹을 비활성화하는 lastpipe^영어 옵션을 가지고 있다.^[13]

5. 프로그래밍 방식의 파이프 생성

`pipe()` 시스템 호출은 운영 체제에 새로운 파이프 생성을 요청한다. 이는 읽기 전용과 쓰기 전용, 두 개의 파일 디스크립터를 생성한다. 파이프 끝은 탐색 기능을 제외하면 일반적인 익명 파일 디스크립터와 동일하게 취급된다. 읽기 전용 파이프에 대한 읽기 명령은 쓰기 전용 파이프에 데이터가 기록될 때까지 차단된다.

교착 상태를 피하거나 병렬성을 활용하기 위해, 하나 이상의 파이프를 가진 유닉스 프로세스는 `fork()`를 호출하여 새 프로세스를 생성한다. 각 프로세스는 데이터를 생성하거나 소비하기 전에 사용하지 않을 파이프 끝을 닫는다. 또는, 프로세스는 새 스레드를 생성하고 파이프를 사용해 스레드 간 통신을 할 수 있다.

쓰기용 파이프와 읽기용 파이프를 서로 다른 프로세스가 가짐으로써 스트림을 공유하고 협조적인 동작을 수행할 수 있다. 이는 `fork`된 부모 자식 관계에 있는 프로세스 간의 프로세스 간 통신에 사용된다.^[14]

6. UNIX 계열 이외 OS의 유사 기능

유닉스의 파이프 기능은 MS-DOS, VM/CMS, MVS의 CMS 파이프라인 패키지 등 다른 운영 체제에서도 차용되었으며, 이는 소프트웨어 공학의 파이프 및 필터 설계 패턴으로 이어졌다.

6. 1. MS-DOS

유닉스의 이 기능은 MS-DOS 등 다른 운영 체제에서 차용되었다.^[1] MS-DOS의 파이프는 싱글 태스크 OS라는 제약 때문에 중간 파일을 통해 동작이 에뮬레이트되었으며, 단순한 약기법에 불과했다.^[1]

6. 2. Windows의 명명된 파이프

Windows에서는 `CreateNamedPipe()` 함수를 사용하여 "\\\\.\\pipe\\파이프명" 형식으로 이름 있는 파이프를 생성할 수 있다. 클라이언트는 파일 입출력과 동일한 방식으로 파이프에 접근하여 읽기/쓰기를 할 수 있다. Windows에서 익명 파이프는 이름 있는 파이프를 기반으로 구현된다.

이름 있는 파이프는 머신 간 통신에도 사용될 수 있지만, 데이터 전송 시마다 확인 응답을 주고받아야 하므로 대량의 데이터를 다른 머신과 통신할 때는 소켓이 더 효율적이다. 반면, 머신 내 프로세스 간 통신에서는 Windows 커널에서 이름 있는 파이프가 작동하므로 더 빠르다.

참조

_[1] 웹사이트 The Creation of the UNIX Operating System http://csdev.cas.upm[...] Bell Labs
_[2] 간행물 A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 http://www.cs.dartmo[...]
_[3] 간행물 UNIX Programmer's Manual Third Edition https://dspinellis.g[...] 1973-02
_[4] 웹사이트 The Unix Oral History Project: Release.0, The Beginning http://www.princeton[...]
_[5] 웹사이트 Prophetic Petroglyphs http://www.bell-labs[...] 2022-05-22
_[6] 웹사이트 Pipes: A Brief Introduction http://www.linfo.org[...] The Linux Information Project 2024-01-07
_[7] 웹사이트 Dartmouth Timesharing http://www.cs.rit.ed[...] 2024-01-07
_[8] 웹사이트 Data https://www.bell-lab[...] 2022-05-22
_[9] 웹사이트 Bell Labs and CSP Threads https://swtch.com/~r[...] 2024-01-07
_[10] 문서 Ritchie & Thompson, 1974
_[11] 웹사이트 Bash release notes https://tiswww.case.[...] 2017-06-14
_[12] 웹사이트 Shell Loop Interaction with SSH http://72.14.189.113[...] 2012-03-06
_[13] 웹사이트 How can I store the "find" command results as an array in Bash https://stackoverflo[...]
_[14] 링크 Advice from Doug Mcilroy http://cm.bell-labs.[...]
_[15] 문서 この例に使用するカッコは、サブシェルで実行することを意味する ( ) である必要はなく、単なるグルーピングである { } で構わないがそうすると最後に ; が必要であるなど構文的に煩雑なため、( ) を使っている。
_[16] 문서 パイプの場合はこのような順序で理解すれば良いが、ファイルへのリダイレクトにおいて、2>&1 >filename という順序ではうまくいかず、>filename 2>&1 という順で書かねばならない、というのがなぜなのか、を正しく理解するのは少々骨が折れる。
_[17] 링크 Pipes: A Brief Introduction http://www.linfo.org[...]
_[18] 문서 シェルの構文とpipeシステムコールを、本来きちんと分けて書くべき。
_[19] 링크 http://www.cs.rit.ed[...]
_[20] 웹사이트 The Evolution of the Unix Time-sharing System http://cm.bell-labs.[...] 1996
_[21] 문서 Sal Soghoian on MacBreak Episode 3 "Enter the Automatrix"
_[22] 간행물 A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 http://www.cs.dartmo[...]

본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com